BGP Community
BGPのNLRIに付与するattributeのうちの一つ。 要は広報経路毎に付けられるタグ
何かのアクションのトリガーに利用される。
よくありがちなのは拠点ごとにその拠点ごとの専用コミュニティを付与しての経路識別
Peer、Customerから受け取ったBGP routeの識別をしてどちらを優先して使わせるかの識別に使わせたりする。
ただのタグなのでタグをフックして何かをするアクションを用意しなければ、何の意味もない。
主な用途はBGP peerであるリモートルーターにタグに応じたアクションを指示する
顧客経路や自社内の経路といった経路ごとの区別をつけるのに利用される。参考 RTBHの仕組みはこのBGP communityつけた経路をトリガーにして発動したりする。 どのようにcommunityをつけて実現するかは各社バラバラ。
各社がどのようなbgp communityを公開しているかはここ 例えばNTTCOMでは次のcommunityを付けることで対象prefixをブラックホール化
特定のregionにのみAS path prependをさせて広報させたりといったことができる。
DDOS攻撃を受けた際に上位ASで特定prefixをブラックホール化させたりとかはしばしば便利。
code: example
2914:436 50 only beyond the connected region
2914:4421 prepend o/b to all peers 1x in Asia
BGP Extended Community
BGP attribute type code 16として定義されている。
Extended community自体は既存のbgp communityだけでなく、
現実のBGP communityはこのBGP Extended Comunityを指すケースが多い。
BGP Extended community Field
大本の定義としては単純に Type filedとvalue fieldがあるだけ。
このフォーマットの中でvalue filedの部分を自由にフォーマットを決めてつかっているというのが現状。
code: field
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low(*) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
一般的にBGP communityと言われるときに使われるのがこのフォーマット。
Valueの48bitをAS(16bit):community number(32bit)として利用しようとするフォーマット。
code: Two-Octet AS specifi Extende community
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 or 0x40 | Sub-Type | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type highの部分に0x00か0x40をいれているとこのフォーマットとして解釈される。
Glovbal Administrator
ここの16bitは自AS番号
Local Administrator
ここの32bitは自由に使える空間。
人間に見やすくるとたとえば1234:1のような感じ。1番は後述のNO_EXPORTなので,このcommunityをつけた経路はAS1234でNO_EXPORTをつけた経路になる。
近年は4byteASがある。rfc7153。type filedが0x02。 AS(32bit):community number(16bit)`というフォーマットにすることもある。
また根本的なフィールドの狭さに対処するためにlarge bgp community (96bit field)も提案されている。
large bgp community
最初の32bitは自AS番号、次の32bitをaction number, 最後の32bitをtarget number。
たとえば1234:1:123みたいな感じ。ただしここらへんはまだどうするべきかという一般解はない。設計しだい。
Well-known communies
下記はすでに予約されているcommunityである。
これらのcomminityについては明示的に処理を書いてなくても、自動的に動作が発動する場合があるので注意。
no exportとかはわりと使うbgp community
NO_EXPORT (0xFFFFFF01)
NO_ADVERTISE (0xFFFFFF02)
NO_EXPORT_SUBCONFED (0xFFFFFF03)
NOPEER (0xFFFFFF04)
No EXPORT
このcommunityを付与した対象経路をeBGP neighborに広報させない
No ADVERTISE
このcommunityを付与した対象経路をeBGP,iBGPすべてのneighborに広報させない
No EXPORT SUBCONFED
このcommunityを付与した対象経路は同一BGPコンフィデレーションにのみ広報する。
No PEER
このcommunityを付与した対象経路をeBGP,iBGPすべてのneighborに広報させない
Communityの伝搬について
Ciscoルータはcommuniyの情報は他のルータには自動でそのまま伝搬されない。
具体的にはneighborとの設定にsend-communityを設定していないと他のルータから受け取ったcommunityをそのまま伝搬しない(正確にはbgp update時に更新しない)。ただしNLRIはきちんと広報するので注意。
send-communityはneighborごとの設定なので注意しないといけない。
community設計
要は経路への色付けに使うので、実際に利用するケースごとに分けておくとよい。
あまりに広い意味で色付けしていると、後で細かい制御をしたいときに困る。
結局ビジネス的にどういう制御が必要かを事前に想像するのが大事というよくある話。
組み合わせで表現できるように直行性を意識しておくとよい。
細かく分けまくって複数のcommunityの組み合わせで制御する方式もあまり行き過ぎると複雑になるので注意
内部制御用と外部制御用でブロックをわけておくとよい。
用途レベルで当然ブロック単位でわける
外部から制御される用途のcommunityをブロック単位で定義しておけば、外部許可するのはそのブロックだけで済む
communityは正規表現マッチでくくることを考えると、桁ごとに纏めるようなデザインが制御しやすい。
利用例
path prepend
LPの制御
bloack hole発動
経路ごとのexport対象の制御
地域ごととか、顧客、ASごとへの広報制御
xxx:yyyでxxx:*な経路は広報しない、+1 prepndするとか
あらかじめ全ルーターにcommunity定義や制御policyを仕込んでおく必要はある。
communityはAS_NUM: XXXで設計されるケースが多い。
4バイトASは・・・Large communityに期待？
対外に経路を出すときにcommuityは消すこと。
もちろん制御のためならcomuunityは付与するが、基本はリセットするような消去ポリシーをかませる。
経路を受け取る際も制御を許したcommunity以外は消すようにしないと事故る可能性。
使わないなら受け取ったcommunityは一旦全部消したほうがよい。
commnity 利用例
日本のトランジット顧客にJP-CUSTOMER、アジアのトランジット顧客にAP-CUSTOEMRとcommunity付与
PEER,トランジットへの経路広報の際にJP-CUSTOEMR, AP-CUSTOMERのみの経路を広報
仮にアジア ->日本のトラフィックが一時的にDDOS等でトラフィックが多くて困っている場合にはJP-CUSTOEMRの広報経路をアジア拠点で停止とすれば、アジア -> 日本へのトラフィックはへる。
具体的なjuniperでの実装例だとのtermでJP-CUSTEOMER, AP-CUSTOMERの各communityが付与されていた経路だけ広報するような状態にしておく。
緊急事態時は対象termだけdeactivateすることで、一部のcommunityだけが広報されるようになる。
他にもNoAdverterseのような広報しないというcommunityを作成して、全拠点でそのcommunityが付与された場合に広報しないように各peerに設定を仕込んでおけば、一部のpeerへのトラフィック流入が大きい場合にそこのpeerに対してcommunityを後付けで付与することで、そのpeerからの広報だけを簡単に停止できる。